Server- Assisted Public-Key Cryptographic Method 



FIELD OF THE INVENTION 

The present invention relates to a server-assisted computational method for the 
RSA processing that is viable on the resource-constrained devices. The invention is 
relevant to the fields of client-server distributed computing and public-key 
cryptography. 

BACKGROUND OF THE INVENTION 

Public-key cryptography is proven effective as a mechanism for secure 
messaging in an open network where no intermediate routers are presumed 
trustworthy to the end-communicators. The RSA algorithm nowadays represents the 
most widely adopted public-key cryptographic algorithm. 

The RSA core comprises of encoding and decoding modules that are primarily 
exponentiation engines. Suppose (e, n) constitutes the encoding key, the encryption 
process is an exponentiation of the message M being raised to the power e under the 
modulus n to give the cryptograph 5. If (d, n) is the decoding key, the decryption is 
the process that raise S to the power d under the modulus n to recover the original 
message M. 

The RSA technique exploits the un-surmountable complexity of discrete 
factorization to deter any attempts of cracking the key pair (e, d). The technique is 
thus safe for cryptographic purposes. Contemporarily, it forms the underpinning of 
many public-key infrastructure systems for e-business activities on the Internet. 

As e-business is rapidly expanding to the users of wireless handhelds, such as 
mobile phones, a secure transaction protocol that is effective on the wireless domain 
is the most desired technology to the e-business practitioners in order for them to 
seamlessly extend the secure transaction activities from the wire-lined Internet to the 
wireless counterpart. 

Nevertheless, the solution is not straightforward. Public-key cryptography is 
so much resource demanding that the technology has never been feasible on the 
resource-deprived computing devices, such as mobile handheld. 



Interim solutions have been proposed which effect via reduction in security 
functionality or certificate fields in order to fit with the CPU limitation. The public- 
key infrastructure that prevails in the wire-lined world thus takes a reduced form, 
weaker functionality and security strength, when ported to the wireless domain. 

WTLS has been proposed as such a streamlined form of the commonly 
employed SSL security protocol for the wireless world. A concern, however, is the 
incompatibility between the SSL and WTLS domains, resulting in a vulnerable gap at 
the wireless gateway and failing the most desired end-to-end secure message 
tunneling (Figure 1). 

Prior art handles a similar problem of conducting the RS A crypto processing 
on an IC card with load sharing between the IC card and the host computer in a point- 
of-sales setup. In those methods, the encoding or decoding key that represents the 
secret parameter held inside the IC card is broken into bit blocks, e 0f e 2 , e 2 , e h 

e = e 0 +e l -2 k +e 2 -2 2k +~* + e l >2 lk 
M e = (M) e ° -(M 2 V '(M l2k y 2 •■♦(M 2 'V modtt 

The load sharing is done in the way that the host computer conducts the 
exponentiation for the base values of individual blocks (powers of 2 k , 2 2k , 2 lk on 
M) whereas the IC card carries out the intra-block exponentiations (powers of eo, ej, 
e 2 , ei) to obtain the final cryptograph Af . 

As the result, the secret key is well kept by withholding it in the IC card. The 
load sharing is effective. Nevertheless, the comment is that the computational 
requirement on the IC card is still significant. 

The present invention employs a more powerful secrecy model and offloads 
more of the computational requirements to the server side. As a result, the processor- 
heavy RSA becomes practically possible on a resource-poor handheld device. 

When the mobile handheld can act with the regular cryptographic capability, 
the need for a reduced security protocol, such as WTLS, is immaterial. Consequently, 
the mobile handheld can work in full compatibility with the existing Internet SSL 
protocol, and the end-to-end secure tunneling is possible (Figure 2). 
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SUMMARY OF THE INVENTION 

The present invention is a client-server computing method to enable a 
resource-deprived device to accomplish the otherwise overwhelming public-key 
processing. It is made possible by shifting the load of computation to the powerful 
server computer on the Internet. The result is that the client device drives the 
resource-rich server computer to carry out the bulk of the computation for its sake. 
The merit is that the server during the process is totally blinded of the secret 
parameters (the message code and the crypto key) of the client. 

The core of the RSA runtime is the exponentiation operation. During the 
encryption phase, a message code is numerically raised to the exponential power as 
specified by the encryption key. Upon decryption, the original message is recovered 
by another exponentiation using the decryption key on the cryptograph. The technique 
although computationally expensive, is mostly affordable to the Internet computers 
nowadays. 

The present invention enables the handheld to leverage the computing power 
of the Internet server computer to bear the load of the exponentiation computation so 
that the public-key cryptography becomes possible on the handheld in a logical sense. 

Our method employs a more powerful secrecy model in which the key is 
transformed and masked by a bunch of random numbers. Rather than withholding the 
long RSA key (1024 bits), the client can keep a portion of the data (128 bits) that 
correspond to the equivalent search space (2 128 ). With that, the load sharing can be 
attained much more effectively between the client and the server by offloading most 
of the exponentiation computation to the server side. 

The present invention may be understood more fully by reference to the 
following detailed description and illustrative examples which are intended to 
exemplify non-limiting embodiments of the invention. 

The first embodiment is a client-server scheme for the exponentiation 
operation. 

The second embodiment extends on the robustness of the method. 
Intermediate results from the server side are cross-validated against one another to 

3 1288773-1 



discover and thus decline any sabotage attacks from the server side in the case that the 
server is compromised. 

BRIEF DESCRIPTION OF DRAWINGS 

Figure 1 illustrates the security weakspot at the wireless gateway. 

Figure 2 shows the client-driven server-assisted strategy for the public-key 
cryptography. 

Figure 3 is the flowchart showing the first embodiment of the present invention. 
Figure 4 is the flowchart showing the second embodiment of the present invention. 

DETAILED DESCRIPTION AND PREFERRED EMBODIMENT 

The present invention will be more readily understood by referring to the 
following examples and preferred embodiments, which are given to illustrate the 
invention rather than limit its scope. 

The present invention embodies two versions of design. The core of the RSA 
public-key cryptographic processing involves the computation of exponentiation 
operations. As the handheld device is incapable of carrying out the demanding 
processing, it ships the data and crypto parameters to the server computer and makes 
the server compute the exponentiations for it. The handheld, as the client in this 
relationship, ensures the privacy of his secret data and parameters by scrambling all 
the data he sends out to the server (Figure 2/01). 

The server is totally blinded of the client's secrets. It takes the role of an 
exponentiation engine, producing the near-completion result for the cryptographic 
process (Figure 2/02). Upon returning of the exponentiation result, the handheld 
finishes off the entire computation with its unshared secrets to churn out the final 
cryptograph (Figure 2/03) for that cryptographic process. When communicating with 
the cryptograph, the handheld is guaranteed end-to-end security as no third party has 
the key to reveal the original message code. 

In the similar process, the end-to-end security is achieved during the 
deciphering phase as well. A private message is sent to the handheld (Figure 2/04). 
The handheld as the client drives the server computer to carry out the exponentiation 
processing to arrive at a near-completed decryption result (Figure 2/05), Upon 
receiving the result, the handheld completes the decryption process with its unshared 
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secrets (Figure 2/06), Consequently, the most desired end-to-end communication 
model is secured. 



In the following sections, the mathematical formulation and the 
communication protocols of the two embodiments are detailed. 

EMBODIMENT 1 

The first embodiment reformulates the RSA algorithm as a client-server 
computational scheme. In the scheme, the secret hiding for the message code and the 
client's crypto key is well considered. 

As the formulation of the RSA algorithm is symmetric for both encryption and 
decryption, we simplify the discussion by posting the encryption case only. The 
resulting client-server scheme is also applicable for decryption case without 
modification. 

A. Client-server model for Exponentiation 

The goal is to shift to the server computer the load of calculating the 
cryptograph S from the message M and the crypto key e. 

S = M e mod /i (i) 
The exponent e is broken into components e i9 i = \ 9 ...Jc. 



The ry terms in (2) are integers of small-values. To hide M and e from the server, the 
client scrambles M and the e-components with random numbers. For n=p< q, we have 



e = e l (r l2 -r ll ) + — + e k (r k2 -r ti ) 



<j>=(p-l){qA). Then 



M = (a - M) mod/2 



(3) 



e n =(e / +fi i -r n )mo<ty 
e n =«(c,+tt,-r l2 )mod^ 



;/ = !,—,* (4) 



Define partial terms z i} =M e " modn . Expand with (3) and (4), 
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z R =(a-M) eM mod« 
z a =(a-M)- (e ' + "' ,;j) modn 



(5) 



Solve (5) for M*<*-»\ 




h r,2 -V"))mod>/ (6) 



Now, the last step follows the expression (2) and puts the k components as calculated 
in (6) together to derive the cryptograph S. 



In a preprocessing phase, the client generates and stores in its memory the 
random numbers a, A. The job can be done by the client during its idle time or pre- 
computed by another computer and downloaded to the client in a secure channel. The 
actual implementation is flexible for this step. 

During the runtime, the client generates the random decomposition of e as in 
(2,4), and scrambles the message M as in (3). The client then ships the data to the 
server where the partial terms zys are computed (as in (5)). Upon receiving the partial 
terms in return, the client computes (7) to obtain the cryptograph. 

Referring to Figure 3, the client-server protocol is carried out in four steps: 

1) Pre-processing (Figure 3/01) 

The random number a and its reciprocal A are generated as the parameters for 
scrambling the message code (in (3)) before sending it to the server, and for de- 
scrambling for the final cryptograph after the partial terms have been returned from 
the server (in (7)). 

2) Client generates random numbers (Figure 3/02) 

The client generates a random decomposition of the crypto key e into a set of e t j 
components. It is intended to ask the server to compute the partial terms of M e,j . 




where a e 'A = l(modn) 



B. 



The client-server protocol 
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In order to hide the information from the server, the message code is scrambled 
with a to give M , and the ey set is randomly re-ordered to give {e & } . 

With such scrambling and random-ordering, the server should have no easy way 
to guess out how the client derives the final cryptograph at the end. 

The data M , {e- } are then communicated to the server for the exponentiation 
computation. 

3) Server computes exponentiations (Figure 3/03) 

Upon receiving the scrambled data M , {e £J } from the client, the server calculates 
the exponentiation terms z i} as in (5). 

These z & partial terms are sent back to the client then. 

4) Client derives cryptograph (Figure 3/04) 

Having received the set of z & partial terms, the client reorders the set and extracts 
the relevant values for the z fj terms. It then calculates the final cryptograph S as in (7). 

C. Potential Attack is Minimum 

Potential attack at this stage involves the guesswork for the ry values. Such 
attacks are extremely difficult to work out. If we choose k = 1 1, we have 22 r t j terms. 
Even each term has a value no larger than 63, the search space for the guesswork is 
already as large as 63 22 = 10 39 s2 128 , which would readily satisfy the security 
requirements of the nowadays Internet applications. 

D. Efficiency Consideration 

The computational burden for the client comes mostly from the calculation of 
(7). Eq. (7) requires modular exponentiations and multiplications. As commonly 
known, a batch of exponentiations can be carried out in a procedure of 
multiplications, and the number of multiplications is related to the bit length of the 
exponents and the number of exponentiations to be done in the batch. 
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By the above case of 22 exponentiations and each exponent is no larger than 
63 (bit length is 6), the worst case would reckon roughly 132 modular multiplications 
and the average case is roughly 66. 

In the comparison with the regular RSA, an exponentiation operation using a 
1024-bit encoding key requires modular multiplications in the order of 2 times the 
encoding key length, i.e. 2048. Compared with that, the method by this embodiment 
presents a saving factor of 15 times or more to the client device on its CPU demand. 

EMBODIMENT 2 

This method extends the first embodiment on the robustness of the client- 
server model. The former method does not anticipate sabotage attacks from the server 
side. The client takes the server calculations to the final cryptograph result by Eq. (7) 
without hesitation. 

However, in the case that the server were compromised, the client might 
subject to attacks of malicious data manipulation. Hacker on the server might forge 
the Zij values either by manipulating the M , {e i} } data sent to the server, or might fake 
the Zy values altogether. 

This method curbs sabotage attacks by taking the server calculation through 2 
iterations and cross-verifying the results to discover any happenings of server-side 
forgery. 

A. 2-iteration model with cross-verification 

Essentially, the method calculates M 6 in 2 iterations of exponentiation. 
Forgery in any one of the iterations will get magnified in another. Without the 
knowledge of the client's secret parameters for those iterations, the attacker has no 
way to fake through the entire process. 

The mathematical formulation is presented in the following. We decompose 
the exponent e (ref. (2)) with disparate parameters in 3 different formulations as 
follows. 
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(2.3') 



e = fa -Sa +K 

= (h a +s)-g b +h b (2.1') 

= f a -g a +(h+e)-g b +K 

M e =(M f ") s ° •M K 

= {M h " -M £ ) Sb •M h " (2.2') 
= (M f -) s - (M h ° -M e Y b -M K 

And, the respective exponent terms, fa, go, ha, gb, hb, h c , are decomposed like it was 
done in (2). 

fa ~ fa\ ( r al2 — T a\\ ) "* *" fak ( r ak2 — r ak\ ) 

ga = gal ( S al2 ~ S al 1 ) + * ' ' + Sat ( S «k2 ~ S ak\ ) 

gb = gb\ (*M2 ~ 5 M1 ) + * * * + gbk ( S bk2 ~ S bkl ) 

K = K\ {hn - Ku ) + "• + h ak (Kkl ~ Kkl ) 

K = K (hn ~ hn ) + ••• + hk ( t bk2 - hki ) 
h c = h d (fen - 'cii ) + -- + h ck ifck2 - Ux ) 

We scramble M in the same way as in (3) with the mask a. 

M = a-M modn (3) 

For the exponent terms, the random scrambling this time is done as follows. For 
i = l,--,k and y' = l,2 : 

fan = (fai + U i ■ r ail ) fai2 = ~(fai + U i ' r al2 ) 

gail = (gai + V ai " S cil ) g ail = ~(« ai + V ai ' ^2 ) 

2ui = (g« + V W • S M ) S«2 = -(«"« + V U ■ S H2 ) 

*«fl = ( A <tf + W <z.- • Kil ) A«2 = ~(Ki + W a> • tail ) ^ ' 

Kn = (K + w m ■ hn ) Ki2 = -(^w + w m • *ta ) 
*di = iKi + w d • tax ) A «2 = + W d • r rf2 ) 

In the 1 st iteration, the z,y terms are defined for the first-level exponentiation of (2.2') 
with respect to the exponent terms fa, h a , h and h c . 

z /a& = M fa " modn 
Zhaij =M h °« mod* 

z Ai , = M 1 " modn 1 ; 

z *c/,- = M K,J modrc 
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These z i} terms from (5') are combined to give the partial cryptographs, 
S fa Aa ,S U ,S hc ,as defined in below. 



S ha =b h -M h '-M* 
S hc =M"< 



where M f ° = ^t[^ fail r " 2 ■ z ^jjmodn 
^ Ao= [fl(^a ,a ' 2 -^"' , )] modw 

^ Ai= (n(w fa2 -w M )]mod« 



(7') 



Now in the 2 nd iteration, the partial cryptographs are fed through the exponentiation 
process for one more time to complete (2.2') with the second-level exponentiation. 
We define another set of partial terms, z fij ,z hij , for this iteration. 



z fiJ =S fo ^modn 

z hiJ =S ha s »modn V } 

Similar to (7'), the partial terms are combined to give the partial cryptographs. 



s,=(s fa y° =(vn(v™ 2 • V" , )) mod » 

S 2 = =\b„ -fl(z m ^ -^''jjmodn (9>) 



where b f Sa B f =1 (modn) 
b h gb -B h sl(modn) 

The final cryptograph S now can be derived with the partial cryptographs from 
(9 5 ). From the formulation of (2.2'), three versions of S can be calculated. 

S l =A-S l -S ha =(M f «Y« -M K modn 

S 2 =A>S 2 -S hb =(M ha -M £ ) Sb -M hb modn ( 10 >) 
S 3 = A-S r S 2 -S hc =(M fa ) ga -(M ha -M £ ) 8b -M K modn 
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The rationale for 3 different formulations for S is to build the mechanism in 
the process for cross-verification on the calculation of S. Agreement of the 3 versions 
indicates the validity of the server-side calculations. Hence, if iS/ = 3? = S3 in (10'), the 
calculations are considered to be correct, and any one of the three can be reported 
with confidence for the final cryptograph S. 

B. The client-server protocol 

1) Pre-processing (Figure 4/01) 

Like it in the Embodiment 1, the random number a, and its reciprocal A, are 
generated as the parameters for scrambling the message code in (3), and for de- 
scrambling for the final cryptograph in (10'). 

In addition, two sets of random numbers, (g a , bf, Bf) and {gb, fa, Bh), are 
generated and stored in this pre-processing stage. The values g a and gb are to be used 
in (2, 1 ') whereas (bf, Bf) and (b h , Bh) are the reciprocal pairs used in (7') and (9 5 ). 

2) Client generates random numbers (Figure 4/02) 

During runtime, the client generates the random decomposition of the crypto 
key e into the set of f aiJ , h ai j , huj and h ciJ terms (ref. (2') and (4')). Note that the s in 
(2') as well as the r aiJ , s ai j t Sby> t a y, hy and t cij terms in (4') are all small integers such 
that the exponentiations with them by the client in the subsequent steps 4 and 6 are 
manageable. 

The client scrambles M with a as in (3) to give M . The f ai j , h a y , h ci j and /* c // 
terms are all mixed in one single pool and randomized in their ordering. Let the 
randomized sequence be referred as {e^} . 

The scrambled M and the randomized exponents {e-} are sent to the server 
for computing the exponentiations. 

3) Server computes exponentiations (Figure 4/03) 

Upon receiving the scrambled data, M and {e & } , from the client, the server 
calculates the exponentiation terms z tj = M e ' J . 
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4) Client calculates partial cryptographs 
(Figure 4/04) 

When the z i} partial terms are returned from the server side, the client undoes 
the random ordering of the set {z. } to obtain the values for the respective terms of 

Zfaiji Zkaij> Zhbij? and Zjidj . 

The client then calculates S fa9 S ka , S kb9 S kc as in (7'). 

The client also calculates the decomposition of g a and gb for the sets of {g aiJ } 
and {g biJ } (ref. (V) and (4')). Data of (S fa , {g aij }) and {S ha , {g biJ }) are sent to the 
server for the 2 nd iteration of exponentiation. 

5) Server computes exponentiation of 2 nd iteration 
(Figure 4/05) 

The server computes the z fij values in (8') when S fa , {g aij } are received. By 
the same logic, it computes z hij on the received data S ha , {g bij } . 

The results are then returned to the client side. 

6) Client derives and verifies final cryptograph 
(Figure 4/06) 

The client derives the cryptograph in (9') and (10'). 

Three versions Si, S2 and S3 are calculated. At this point, the client verifies the 
validity of these cryptographs against possible attacks from the server side by testing 
whether Sj, S2 and S 3 all agree with each other. Testing positive, the client reports any 
one of the three as the final cryptograph S = M e . 

C Verification Test is Effective 

The verification test by the 2-iteration scheme is strong and tight in the sense 
that any malicious manipulation and forgery will be detected and prevented thereby. 

Consider how the server-side attack could sabotage the overall calculation for 
S = M e . Hacker breaking in the server could intercept the exponentiation processes 
as laid out in (5') and (8'). These calculations are in the form of Z = X Y . Hence, the 
hacker could launch any of the following 3 attacks: 
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1. Manipulating X 

2. Manipulating Y 

3. Forging Z 

5 1 st form of Attack - Manipulating X. 

The hacker could manipulate the M value in (5'), and thus faked the values 
for M f %M h %M h \M hc in (10'). Note that the calculation of M E is kept to the 
client side, and thus is safe from attacks. As the hacker has no way to estimate the 
impact of M s in the equation system (10'), he cannot manipulate M in such a way 
10 that the effect is coherent across Sj> S2 and S5, Hence, such attack is difficult. 

2 nd form of Attack- Manipulating Y. 

The hacker could manipulate the exponents f a , h a , h c and g a9 gb by forging 
their values in the calculations of (5') and (8'). However, any manipulation onf a and 
g h a will get magnified by the factors of g a and gt in the 2 n iteration, which are 

Q 15 unknown to the hacker throughout the process. Therefore, the hacker indeed has no 

\\ way to control his sabotage on Si, S2 and S3 in (10') in a coordinated fashion so as to 

H 

H fake it through the entire verification test. 

P 3 rd form of Attack ~ Forging Z. 

py In this case, the hacker could return a forged value for the z term as if it were 

20 calculated from (5') to sabotage the calculation of (10'). However, it is practically 
impossible to do so because any forgery on the z values sabotaging Si will be routed 
through S fa and S ha before landing on (10'). The hacker would have no way to 

predict and control the impact of S fa and S ha during the 2 nd iteration due to his null 
knowledge of g a and g b . 

25 Moreover, neither could the hacker return a forged value for z as if it were 

from (8'). Imagine that the hacker faked some z values in (8') to give S x and S 2 that 
were seemingly good for the test of (10'). Since 2 alterations (S } and S 2 ) cannot 
satisfy a 3-way agreement (among Si, S2 and S3) at the same time, the attack is 
essentially not possible. 
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D. Other Attack Consideration 

Hacker trying to crack the private key e (2.1') would have to involve himself 
in the guesswork for the private data in the client's calculations of (7') and (9'). Take 
the first formulation of (2.T) for example, the hacker with the z values known to him 
from (5') and (8') would have to match the z values to the formulas in (7') and (9') 
and guess out the values for the r m y, s a y and t a tj terms for the calculation. 

If we choose k =4, we will have 8 f ai j, 8 g aij and etc. in (4'). That will give 32 z 
values in (5'). Suppose the r aiJ , s a ij and t ai j terms all have values ranging from 1 to 15. 
Matching up the z values to the formulas in (7') and guessing the r aiJ , s a ij and re- 
values for calculation of the formulas would cost 

i) C(32,8) • 15 8 searches for the calculation related to r ai /s in (7') 

ii) C(24,8)45 8 searches related to t a t/s in (7') 

iii) 15 8 searches related to s ai /s in (9'). 

Altogether the hacker will be running up against a search space of 

C(32,8)45 8 <C(24,8)'15 8 -15 8 = 10 41 = 2 12S 

Security strength by such search space is satisfactory. 

E. Efficiency Consideration 

The computational burden for the client this time is primarily due to (7') and 
(9'). There are 6 formulas of exponentiation to be evaluated. By the same analysis we 
did in the previous embodiment, the number of exponentiations to be carried out in 
(7') and (9') together is 48. As the exponents are 4-bit numbers, the worst case would 
reckon roughly 192 modular multiplications and the average case is roughly 96. 

Compared with the 2048 multiplications in the regular 1024-bit RSA, this 
method gives the client device a saving factor of 10 or more on the CPU demand. 

A number of references have been cited, the entire disclosures of which are 
incorporated herein by reference. 
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